Amazon FSx for NetApp ONTAPファイルシステムの最大ストレージサイズは実質無制限
NFSやSMBで接続できる領域に無制限にファイルを保存したい
こんにちは、のんピ(@non____97)です。
皆さんはNFSやSMBで接続できる領域に無制限にファイルを保存したいと思ったことはありますか? 私はあります。
「Amazon S3 File Gatewayを使ってS3にデータを保存すれば良いんじゃないの?」と思われるかもしれません。しかし、私はEC2インスタンスの管理をしたくないのです。
ここで、Amazon FSx for NetApp ONTAP(FSx for ONTAP)ファイルシステムの出番です。
AWS公式のAmazon FSx ファイルシステムの比較資料を確認すると、FSx for ONTAPのファイルシステムの最大サイズは実質的に無制限(数百 PB)となっています。
抜粋 : Amazon FSx ファイルシステムの選択のサポート
何故、実質無制限なのかというと、FSx forONTAPファイルシステムには、プライマリストレージとキャパシティプールストレージの2つのストレージ階層があり、キャパシティプールストレージは容量上限がないからです。
???
となっていること間違い無いので、次章から詳細を説明します。
いきなりまとめ
- FSx forONTAPファイルシステムには、プライマリストレージとキャパシティプールストレージの2つのストレージ階層がある
- プライマリストレージはSSDストレージ
- SSDストレージなので読み書き速度が速い
- アクセス頻度の高いデータを保存する
- FSx forONTAPファイルシステム作成時にプロビジョニングする
- キャパシティプールストレージはペタバイトサイズにスケールできるストレージ
- 裏でオブジェクトストレージに保存されるのでプライマリストレージに比べて読み書きが遅い
- アクセス頻度の低いデータを保存する
- 容量上限なし
- ただし、ボリューム(FlexVolume)1つあたりの最大サイズは100TBなので注意
- プライマリストレージの料金と比較して安価
- 読み込み書き込みに課金が発生する
- FSx for ONTAPはアクセスパターンに応じてプライマリストレージとキャパシティプールストレージをブロックレベルで自動的に階層化する
- 階層化のポリシーは以下4パターン
Auto: アクセス頻度の低いブロックを移動Snapshot Only: スナップショットのみ移動All: メタデータを除く全てを移動None: 階層化を行わない
- ボリュームサイズはプライマリストレージとキャパシティプールストレージの合算
- キャパシティプールストレージによってボリュームで使用可能な領域が増える訳ではない
Amazon FSx for NetApp ONTAPファイルシステムのストレージの仕組み
FSx for ONTAPでは先述の通り、プライマリストレージとキャパシティプールストレージの2つのストレージ階層があります。
プライマリストレージは高速なSSDストレージです。FSx for ONTAPファイルシステム作成時にプロビジョニングするストレージはこちらです。
一方、キャパシティプールストレージはペタバイトサイズにスケールできるストレージです。こちらのストレージはFSx for ONTAPファイルシステム作成時に意識することな利用できます。
抜粋 : 1640 AWSマネージドサービス上のONTAPはデータファブリックの夢を見るか？ - YouTube
キャパシティプールストレージのサイズはAWS公式ドキュメントでは度々「実質無制限」と紹介されていますが、実際は176PiBまでスケールできるようですね。
ONTAP (a NetApp product) is an enterprise data management offering designed to provide high-performance storage suitable for use with Oracle, SAP, VMware, Microsoft SQL Server, and so forth. ONTAP is flexible and scalable, with support for multi-protocol access and file systems that can scale up to 176 PiB. It supports a wide variety of features that are designed to make data management cheaper and easier including inline data compression, deduplication, compaction, thin provisioning, replication (SnapMirror), and point-in-time cloning (FlexClone).
ただし、ONTAP 9.11.1の通常のボリューム(FlexVolume)の1ボリュームの最大サイズは100TBです。100TB以上のボリュームを用意したい場合はFlexGropを使用する必要があります。FlexGroupを使うことで最大20PBのボリュームを用意することができます。そのため、すべてのデータをキャパシティプールストレージを使うようにしていても1ボリュームの最大サイズは20PBになります。以上のことから、176PiBというのは1ボリュームではなくて複数のボリュームの合計サイズのことを指しているのではと予想します。
FlexGropの詳細は以下NetApp公式ドキュメントをご覧ください。
少し話が横に逸れました。
FSx for ONTAPファイルシステムに保存されたデータは階層化ポリシーに応じてプライマリストレージとキャパシティプールストレージをブロックレベルで自動的に階層化します。階層化のポリシーは以下4パターンあります。
Auto: アクセス頻度の低いブロックを移動Snapshot Only: スナップショットのみ移動All: メタデータを除く全てを移動None: 階層化を行わない
キャパシティプールストレージにあるブロックを読み取ると自動的にプライマリストレージに移動します。なお、シーケンシャルな読み取りはキャパシティプールストレージのようです。
- 自動 は、アクティブなファイルシステムとスナップショットコピーの両方のコールドユーザーデータブロックをストレージプール層に移動します。
データがランダムにストレージプール層から読み取られると、ストレージ層のコールドデータブロックがホットになり、プライマリストレージ層に移動します。インデックススキャンやアンチウイルススキャンに関連する読み取りなど、連続読み取りで読み取ると、コールドデータブロックはコールドのままになり、プライマリストレージ層に移動しません。
スナップショットのみ アクティブなファイルシステムに関連付けられていないボリュームスナップショットコピーのユーザーデータブロックをストレージプール層に移動します。
読み取りを行うとストレージ層のコールドデータブロックがホットになり、プライマリストレージ層に移動されます。
すべて は、スナップショットコピーとアクティブファイルシステムの両方のコールドユーザーデータブロックをストレージプール層に移動します。
読み取りの場合、ストレージプール層のコールドデータブロックはコールドのままで、プライマリストレージ層に書き戻されません。
なし (デフォルト) ボリュームのデータをプライマリストレージ層に保持し、ストレージプール層に移動しないようにします。
ストレージ階層化の詳細はNetApp公式の動画でよく説明されています。
動画内14:25頃の説明によると、ストレージプールキャパシティは内部的にはオブジェクトストレージが使われているようです。
ONTAP 9.8からGAになったONTAP Simple Storage Service(ONTAP S3)を恐らく活用しているのではないかと考えます。
内部的にオブジェクトストレージが使われているとなると気になるのは性能ですよね。
FAQにはキャパシティープールストレージ内のデータに数十ミリ秒のレイテンシーでアクセスできるようになっていると記載があります。
低レイテンシーアクセス
Amazon FSx for NetApp ONTAP では、一貫してサブミリ秒のレイテンシーで SSD ストレージ上のデータにアクセスすることができ、さらにキャパシティープールストレージ内のデータに数十ミリ秒のレイテンシーでアクセスできるように構築されています。レイテンシーやパフォーマンスに敏感なワークロードに対して、高速で一貫したパフォーマンスを実現します。
レイテンシーが数十ミリ秒だとしても、レイテンシーが大きくなってしまうと聞いてしまっては階層化ポリシーをAutoにするのは躊躇してしまいますよね。そういった「ちょっとアクセスしなかっただけでレイテンシーが大きくなるオブジェクトストレージに移行されるのは困る」という方のために、階層化のクーリング期間が設けられています。クーリング期間はAutoとSnapshot Onlyで選択可能で、範囲は2～183日間です。この設定はFSx for ONTAPのボリューム単位で行います。
また、階層化のための最小冷却期間を指定することもできます。これによりデータがコールドとみなされ、ストレージプール階層に移動される前に、ボリューム内のユーザーデータが非アクティブのままになる必要がある時間を設定します。Snapshot Only および Auto 階層化ポリシーに適用される最小冷却期間で、範囲は 2～183 日間です。(デフォルトでは Snapshot Only は 2 日間で、Auto ポリシー は 31 日間です。)
プライマリストレージとキャパシティプールストレージの料金
プライマリストレージとキャパシティプールストレージとで料金が異なります。
| 項目 | ストレージの圧縮と重複排除を有効にした料金設定* | 料金 |
|---|---|---|
| SSD ストレージ容量 | 毎月の GB あたり 0.0525USD | 毎月の GB あたり 0.150USD |
| 使用した標準キャパシティープールストレージ | 毎月の GB あたり 0.0083USD | 毎月の GB あたり 0.0238USD |
| バックアップストレージ | 毎月の GB あたり 0.0175USD | 毎月の GB あたり 0.050USD |
| スループットキャパシティー | 毎月の MBps あたり 0.906USD | 毎月の MBps あたり 0.906USD |
| SSD IOPS | 毎月の IOPS あたり 0.0204USD | 毎月の IOPS あたり 0.0204USD |
| キャパシティープールの読み取りリクエスト | 1000 リクエストあたり 0.0004USD | 1000 リクエストあたり 0.0004USD |
| キャパシティープールの書き込みリクエスト | 1000 リクエストあたり 0.0047USD | 1000 リクエストあたり 0.0047USD |
*汎用ファイル共有ワークロード向けの圧縮と重複排除による節約
NetApp ONTAP ファイルシステム管理の料金 – Amazon Web Services
プライマリストレージとキャパシティプールストレージをのデータの保存にかかる料金を比較すると、キャパシティプールストレージはプライマリストレージの1/6以下の料金で使用できます。ただし、キャパシティープールストレージにあるデータを読み書きする際にも課金が発生するので注意が必要です。
階層化と課金のイメージはNetApp公式動画内14:45頃の以下スライドが非常に分かりやすいと思います。
抜粋 : 1640 AWSマネージドサービス上のONTAPはデータファブリックの夢を見るか？ - YouTube
やってみた
検証方法の整理
それでは検証をやってみたいと思います。
検証は階層化ポリシーをNoneもしくはAllにした場合、それぞれボリュームサイズがどのように見えるのかを確認してみます。
検証で使うボリュームは以下の通りです。
{
"Volume": {
"CreationTime": "2022-06-13T02:10:09.876000+00:00",
"FileSystemId": "fs-0967312eff2f5f5e1",
"Lifecycle": "CREATING",
"Name": "volume_tiering_test",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/volume_tiering_test",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 10240,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0a3a78e7c64ff2c5d",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"Name": "NONE"
},
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:ap-northeast-1:558476238088:volume/fs-0967312eff2f5f5e1/fsvol-09324531b76f1dedf",
"Tags": [
{
"Key": "Name",
"Value": "volume_tiering_test"
}
],
"VolumeId": "fsvol-09324531b76f1dedf",
"VolumeType": "ONTAP"
}
}
階層化ポリシーがNoneの場合
まず、階層化ポリシーがNoneの場合です。
検証の前に現在のボリュームの使用量を確認しておきます。
# ボリュームの使用率の確認
FsxId0967312eff2f5f5e1::> volume show -volume volume_tiering_test
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
classmethod-dev-fsx-netapp-ontap-single-az-svm
volume_tiering_test
aggr1 online RW 10GB 9.50GB 0%
# プライマリストレージとキャパシティプールストレージのサイズの確認
FsxId0967312eff2f5f5e1::> volume show-footprint -volume volume_tiering_test
Vserver : classmethod-dev-fsx-netapp-ontap-single-az-svm
Volume : volume_tiering_test
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 296KB 0%
Footprint in Performance Tier 992KB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 61.95MB 0%
Delayed Frees 696KB 0%
Total Footprint 62.91MB 0%
Footprint in Performance Tierが100%で、Footprint in FSxFabricpoolObjectStoreが0%であることから、データは全てプライマリストレージにあることが分かります。
ストレージサイズはNetApp ONTAP CLIだけでなく、CloudWatchメトリクスからでも確認できます。AWSマネージメントコンソールからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズを確認してみます。
キャパシティプールストレージが0GBでプライマリストレージが3.29GB使われていますね。
こちらのボリュームをマウントしてみます。
# マウントポイントの作成 sh-4.2$ sudo mkdir /volume_tiering_test # マウント sh-4.2$ sudo mount -t nfs svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test /volume_tiering_test # ディスクサイズの確認 sh-4.2$ df -hT Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 462M 0 462M 0% /dev tmpfs tmpfs 470M 0 470M 0% /dev/shm tmpfs tmpfs 470M 456K 470M 1% /run tmpfs tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 xfs 8.0G 1.7G 6.4G 21% / /dev/mapper/3600a09806c574231752b53784865462f1 ext4 2.0G 6.1M 1.8G 1% /lun/part1 /dev/mapper/3600a09806c574231752b537848654672p2 ext4 2.9G 9.1M 2.8G 1% /lun/part2 svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test nfs4 9.5G 256K 9.5G 1% /volume_tiering_test # マウントされていることを確認 sh-4.2$ mount | grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test on /volume_tiering_test type nfs4 (rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.162,local_lock=none,addr=10.0.10.31)
マウント後、8GBのバイナリファイルをマウントポイント配下に作成します。
# 8GBのバイナリファイルをマウントポイント配下に作成 sh-4.2$ sudo dd if=/dev/urandom of=/volume_tiering_test/testfile bs=1M count=8192 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB) copied, 65.7837 s, 131 MB/s # ディスクサイズの確認 sh-4.2$ df -hT Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 462M 0 462M 0% /dev tmpfs tmpfs 470M 0 470M 0% /dev/shm tmpfs tmpfs 470M 456K 470M 1% /run tmpfs tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 xfs 8.0G 1.7G 6.4G 21% / /dev/mapper/3600a09806c574231752b53784865462f1 ext4 2.0G 6.1M 1.8G 1% /lun/part1 /dev/mapper/3600a09806c574231752b537848654672p2 ext4 2.9G 9.1M 2.8G 1% /lun/part2 svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test nfs4 9.5G 8.2G 1.4G 86% /volume_tiering_test
8GBのバイナリファイル作成後NetApp ONTAP CLIでボリュームサイズを確認してみます。
# ボリュームの使用率の確認
FsxId0967312eff2f5f5e1::> volume show -volume volume_tiering_test
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
classmethod-dev-fsx-netapp-ontap-single-az-svm
volume_tiering_test
aggr1 online RW 10GB 1.38GB 85%
# プライマリストレージとキャパシティプールストレージのサイズの確認
FsxId0967312eff2f5f5e1::> volume show-footprint -volume volume_tiering_test
Vserver : classmethod-dev-fsx-netapp-ontap-single-az-svm
Volume : volume_tiering_test
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 8.12GB 1%
Footprint in Performance Tier
8.13GB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 61.95MB 0%
Deduplication 9.92MB 0%
Delayed Frees 7.75MB 0%
Total Footprint 8.20GB 1%
Footprint in Performance Tierが100%で、Footprint in FSxFabricpoolObjectStoreが0%であることから、作成したデータは全てプライマリストレージにあることが分かります。
AWSマネージメントコンソールからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズを確認してみます。
プライマリストレージの使用量が3.29GBから12GBに増えました。キャパシティプールストレージの使用量は変わらず0GBのままです。
この状態で、さらに8GBのバイナリファイルを追加しようとしてみます。
# 8GBのバイナリファイルをマウントポイント配下に作成 sh-4.2$ sudo dd if=/dev/urandom of=/volume_tiering_test/testfile2 bs=1M count=8192 dd: error writing ‘/volume_tiering_test/testfile2’: No space left on device dd: closing output file ‘/volume_tiering_test/testfile2’: No space left on device # ファイルが作成されたか確認 sh-4.2$ ls -l /volume_tiering_test/ total 9852548 -rw-r--r-- 1 root root 8589934592 Jun 13 02:43 testfile -rw-r--r-- 1 root root 1532645376 Jun 13 02:47 testfile2
ストレージの空き容量が足りず、1.5GB程度のファイルしか作成できませんでした。当然です。
階層化ポリシーがALLの場合
次に階層化ポリシーがALLの場合です。
先ほどのボリュームの階層化ポリシーをNoneに変更します。
階層化ポリシーを "ALL" に変更
$ aws fsx update-volume \
--volume-id "$volume_id" \
--ontap-configuration TieringPolicy={Name=ALL}
{
"Volume": {
"CreationTime": "2022-06-13T02:10:09.876000+00:00",
"FileSystemId": "fs-0967312eff2f5f5e1",
"Lifecycle": "CREATED",
"Name": "volume_tiering_test",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/volume_tiering_test",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 10240,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0a3a78e7c64ff2c5d",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"Name": "NONE"
},
"UUID": "f7a1b768-eabd-11ec-8b1b-41bd7f3524dc",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:ap-northeast-1:558476238088:volume/fs-0967312eff2f5f5e1/fsvol-09324531b76f1dedf",
"VolumeId": "fsvol-09324531b76f1dedf",
"VolumeType": "ONTAP"
}
}
# 階層化ポリシーが "ALL" に変更されたことを確認
$ aws fsx describe-volumes \
--volume-id "$volume_id"
{
"Volumes": [
{
"CreationTime": "2022-06-13T02:10:09.876000+00:00",
"FileSystemId": "fs-0967312eff2f5f5e1",
"Lifecycle": "CREATED",
"Name": "volume_tiering_test",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/volume_tiering_test",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 10240,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0a3a78e7c64ff2c5d",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"Name": "ALL"
},
"UUID": "f7a1b768-eabd-11ec-8b1b-41bd7f3524dc",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:ap-northeast-1:558476238088:volume/fs-0967312eff2f5f5e1/fsvol-09324531b76f1dedf",
"VolumeId": "fsvol-09324531b76f1dedf",
"VolumeType": "ONTAP"
}
]
}
階層化ポリシーがALLになったことを確認した後、AWSマネージメントコンソールからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズも確認します。
キャパシティプールストレージの使用量が0GBから10.1GBに増え、プライマリストレージの使用量が12GBから3.6GBに減りました。ストレージ階層の移動が発生したようですね。
NetApp ONTAP CLIでボリュームサイズに変更があるかも確認します。
# ボリュームの使用率の確認
FsxId0967312eff2f5f5e1::> volume show -volume volume_tiering_test
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
classmethod-dev-fsx-netapp-ontap-single-az-svm
volume_tiering_test
aggr1 online RW 10GB 16.26MB 99%
# プライマリストレージとキャパシティプールストレージのサイズの確認
FsxId0967312eff2f5f5e1::> volume show-footprint -volume volume_tiering_test
Vserver : classmethod-dev-fsx-netapp-ontap-single-az-svm
Volume : volume_tiering_test
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 9.48GB 1%
Footprint in Performance Tier
151.4MB 2%
Footprint in FSxFabricpoolObjectStore
9.36GB 98%
Volume Guarantee 0B 0%
Flexible Volume Metadata 61.95MB 0%
Deduplication 55.68MB 0%
Delayed Frees 23.55MB 0%
Total Footprint 9.62GB 1%
Footprint in Performance Tierが100%から2%に減少しました。一方、Footprint in FSxFabricpoolObjectStoreは0%から98%に増加しました。NetApp ONTAP CLIからもストレージ階層の移動が発生したことが確認できました。
ボリュームの使用率はストレージ階層の移動が発生しても99%のままです。どうやらキャパシティプールストレージに移動した分、使用可能な領域が増える訳ではなく、ボリュームサイズはプライマリストレージとキャパシティプールストレージの合算のようですね。
試しに8GBのバイナリファイルを追加しようとしてみます。
# ディスクサイズの確認 sh-4.2$ df -hT Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 462M 0 462M 0% /dev tmpfs tmpfs 470M 0 470M 0% /dev/shm tmpfs tmpfs 470M 456K 470M 1% /run tmpfs tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 xfs 8.0G 1.7G 6.4G 21% / /dev/mapper/3600a09806c574231752b53784865462f1 ext4 2.0G 6.1M 1.8G 1% /lun/part1 /dev/mapper/3600a09806c574231752b537848654672p2 ext4 2.9G 9.1M 2.8G 1% /lun/part2 svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test nfs4 9.5G 9.5G 17M 100% /volume_tiering_test # 8GBのバイナリファイルの作成 sh-4.2$ sudo dd if=/dev/urandom of=/volume_tiering_test/testfile3 bs=1M count=8192 dd: error writing ‘/volume_tiering_test/testfile3’: No space left on device dd: closing output file ‘/volume_tiering_test/testfile3’: No space left on device # ファイルの作成が途中で終了していることを確認 sh-4.2$ ls -l /volume_tiering_test/ total 9869132 -rw-r--r-- 1 root root 8589934592 Jun 13 02:43 testfile -rw-r--r-- 1 root root 1532645376 Jun 13 02:47 testfile2 -rw-r--r-- 1 root root 17629184 Jun 13 02:59 testfile3 # 空き容量が 17MB から 576KB に減少したことを確認 sh-4.2$ df -hT Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 462M 0 462M 0% /dev tmpfs tmpfs 470M 0 470M 0% /dev/shm tmpfs tmpfs 470M 512K 470M 1% /run tmpfs tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 xfs 8.0G 1.7G 6.4G 21% / /dev/mapper/3600a09806c574231752b53784865462f1 ext4 2.0G 6.1M 1.8G 1% /lun/part1 /dev/mapper/3600a09806c574231752b537848654672p2 ext4 2.9G 9.1M 2.8G 1% /lun/part2 svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test nfs4 9.5G 9.5G 576K 100% /volume_tiering_test
やはり、ボリュームサイズ以上の書き込みはできないようです。
2023/1/20 追記 ここから
AWS公式ドキュメントを眺めていると、ボリュームサイズとプライマリストレージ(SSD)とキャパシティプールストレージの関係性が非常に分かりやすい図があったので紹介します。
Storage tiers are the physical storage media for an Amazon FSx for NetApp ONTAP file system. FSx for ONTAP offers the following storage tiers:
- SSD tier – The user-provisioned, high-performance solid-state drive (SSD) storage that’s purpose-built for the active portion of your data set.
Capacity pool tier – Fully elastic storage that automatically scales to petabytes in size, and is cost-optimized for your infrequently accessed data.
An FSx for ONTAP volume is a virtual resource that, similar to folders, doesn't consume storage capacity. The data that you store—and that consumes physical storage—lives inside volumes. When you create a volume, you specify its size—which you can modify after it's created. FSx for ONTAP volumes are thin provisioned, and file system storage is not reserved in advance. Instead, SSD and capacity pool storage are allocated dynamically, as needed. A tiering policy, which you configure at the volume level, determines if and when data that's stored in the SSD tier transitions to the capacity pool tier.
The following diagram illustrates an example of data laid out across multiple FSx for ONTAP volumes in a file system.
The following diagram illustrates how the file system's physical storage capacity is consumed by the data in the four volumes in the previous diagram.
(以下機械翻訳)
ストレージ層は、Amazon FSx for NetApp ONTAPファイルシステムの物理的なストレージメディアです。FSx for ONTAPは、以下のストレージ階層を提供します。
- SSD層 - データセットのアクティブな部分に特化して構築された、ユーザープロビジョニングの高性能ソリッドステートドライブ（SSD）ストレージです。
容量プール層 - サイズをペタバイトまで自動的に拡張する完全に弾力的なストレージで、アクセス頻度の低いデータ用にコストが最適化されています。
FSx for ONTAPボリュームは、フォルダと同様、ストレージ容量を消費しない仮想リソースです。保存するデータ、および物理ストレージを消費するデータは、ボリューム内に格納されます。ボリュームを作成するときに、そのサイズを指定しますが、これは作成後に変更することができます。FSx for ONTAPのボリュームはシンプロビジョニングされ、ファイルシステムのストレージは事前には予約されません。その代わり、SSDと容量プールのストレージは、必要に応じて動的に割り当てられます。ボリュームレベルで構成する階層化ポリシーは、SSD階層に保存されたデータがいつ容量プール階層に移行するかを決定します。
次の図は、ファイルシステム内の複数のFSx for ONTAPボリュームにわたってレイアウトされたデータの例を示しています。
次の図は、ファイルシステムの物理的な記憶容量が、前の図の4つのボリューム内のデータによってどのように消費されるかを示しています。
2023/1/20 追記 ここまで
実質無制限(176PiB)のストレージを使いこなそう
FSx for ONTAPファイルシステムの最大ストレージサイズは実質無制限という紹介をしました。
既存のファイルサーバーから移行する際は、全体のストレージサイズをそのままFSx for ONTAPファイルシステムのサイズにするのではなく、どのぐらいのファイルがアクティブに使われているのかを考慮した上でサイジングするのが良さそうです。
FSx for ONTAPではデプロイ後にプライマリストレージサイズを大きくすることも可能です。まずは、スモールスタートで様子を見るのも良いと考えます。
また、キャパシティプールストレージはプライマリストレージの1/6以下の料金で利用できるということもあり、FSx for ONTAPファイルシステム上でアーカイブ的な使い方をしても良さそうですね。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Amazon FSx for NetApp ONTAP] SMBでファイルオープン中にフェイルオーバーが発生した場合の挙動を確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
